What parts of dxl are run on the client and what on the server?

Hi,

Our IT security group has become very interested in all the dxl I have custody of and am enhancing. One of the things they are concerned about is Man in the Middle attacks between the client and the server and would like me to validate inputs to the server in the dxl code. Does anyone know of documentation or information that explains what is being done in the client and what is being done in the server, how (even if) execution of perms may be partitioned between the client and server, or anything else that might assist me working this out?

 

Thanks,
Daniel


anotherDaniel - Thu Aug 24 18:23:47 EDT 2017

Re: What parts of dxl are run on the client and what on the server?
thsturm - Fri Aug 25 03:49:15 EDT 2017

If I understand the DOORS achritecture right, then DOORS server sends the module content to the client and DXL is only working/available in the DOORS client.

So you must fear the attack on the module contents if the module will be only opened and the server sends the content to the client.

Re: What parts of dxl are run on the client and what on the server?
Mathias Mamsch - Fri Aug 25 04:45:40 EDT 2017

Hi Daniel, 

I am sorry to say that very bluntly - but DOORS has NO effective security - it is a CLIENT ONLY system. The security concept is "security by obscurity". 

As far as I know (and I did a lot of research on that): the DOORS Server is a very simple file server with a concurrent access mechanism - no access validation at all. 

That means: Everyone reverse engineering the protocol can read / modify ANY data on the system without even having an account!

Regarding MITM: You can choose to enable a TLS encryption using certificates between the client and the server. This will effectively prohibit MITM attacks. Still everyone can access the server data once he has access to a DOORS client with a valid certificate. The server does NOT do any logging. 

Long story short: If security is very relevant to your corporation - choose another (a more modern) RM system. If you need details, please contact me privately. 

Regards, Mathias

P.S: I am not sure if in more modern DOORS versions (since 9.3) any of this changed. But I am pretty sure it has not.

Re: What parts of dxl are run on the client and what on the server?
PekkaMakinen - Fri Aug 25 09:48:53 EDT 2017

Mathias Mamsch - Fri Aug 25 04:45:40 EDT 2017

Hi Daniel, 

I am sorry to say that very bluntly - but DOORS has NO effective security - it is a CLIENT ONLY system. The security concept is "security by obscurity". 

As far as I know (and I did a lot of research on that): the DOORS Server is a very simple file server with a concurrent access mechanism - no access validation at all. 

That means: Everyone reverse engineering the protocol can read / modify ANY data on the system without even having an account!

Regarding MITM: You can choose to enable a TLS encryption using certificates between the client and the server. This will effectively prohibit MITM attacks. Still everyone can access the server data once he has access to a DOORS client with a valid certificate. The server does NOT do any logging. 

Long story short: If security is very relevant to your corporation - choose another (a more modern) RM system. If you need details, please contact me privately. 

Regards, Mathias

P.S: I am not sure if in more modern DOORS versions (since 9.3) any of this changed. But I am pretty sure it has not.

You can set logging on the database server, of course it has some performance effects

https://www.ibm.com/support/knowledgecenter/en/SSYQBZ_9.6.1/com.ibm.doors.administering.doc/topics/c_configureserverloggingfile.html

The IBM page describes this change as being from version 9.4 upwards.

Re: What parts of dxl are run on the client and what on the server?
anotherDaniel - Fri Aug 25 13:36:52 EDT 2017

Thank you all for the answers. There must be something more going on between the client and server because DOORS performance is atrocious when the client isn't in the same building as the server. If there was very little data exchange once the file was delivered to the client, I would expect normal use to go at near-normal performance once the module was delivered. Maybe links don't get delivered to the client and that's why everything is so slow?

In any case, I won't probe any more about the security aspect here. Mathias, thank you for the offer of additional information. Once we have digested these answers I may take you up on that.

Daniel